TechLead Conference 2026 powered by connpass
まとめ
世の中のテックリードの人たちが考えていることを知りたかったため参加しました。
特定言語特定分野ではなかったので多様な話を聞けると思ったのと、登壇された方々がまさに業界をリードしている方という印象だったので参加するモチベーションになりました。
AI時代になり多くの業界でジュニアを採用するモチベーションが下がっているように思いますが、それは先細りを招くと感じています。とはいえ、会社によっては目先の生産性が大事な時期もあり、どの時期にどのような人を採用するかがAI時代で変化したのであればテックリードの方々がどのように受け止めているかを知りたいと思いました。
t-wadaさんや広木大地さんからは大胆な発言がいくつもありましたが、それらが経験と実践に裏付けされた言葉だというのがトーク全体から感じられました。
ログ
12:30 - 12:35 オープニング
12:35 - 13:20 (45分) キーノート AI時代のエンジニアリングの原則① 〜AIがコードを書く時代に何が重要になるのか
コードを書く主体が変わった
人間はコードを書かなくなってきている
テスト駆動開発はいまも変わってないが、コーディングエージェントがやる
この20年、テスト駆動開発普及に取り組んできたが、一番普及したのがAIによるこの1年
AIエージェントにソフトウェアエンジニアはどう関わっていくとよいか
伴奏モード、丸投げモードの2つ
伴奏モード
ターミナルで対話したり、claude.mdに進め方を書いたり
変わるところと変わらないところ
AIがコードを書けば書くほど、これがまずい場合の問題発生が前倒しされる
理解容易なコードは人間にもAIにも大事（幸せな一致）
AIは変更耐性が非常に大きい
内部品質の重要性はAIでも人間でも変わらない
内部品質のなかのパワーバランスは変わる
詳細設計をAIと一緒にやっていく: sdd や plan モード
要件定義や企画はやりやすくなった
要件定義でプレーンテキストに近いものを扱うようになった（Excelではなく）
コードの近くに置くようになった
コードを管理するように文章も管理する
既存資産をもつ企業では、資産Excelをどうテキストにするか、どうAIに読んでもらうかに取り込んでいる
整然とした情報は扱いやすい、乱雑な情報は扱いづらい
AI時代のエンジニアリングの原則
底上げではなく、増幅される
ソフトウェア開発が得意な企業は、得意が増幅される。カオスな企業はカオスが増幅される。
AI以前はDXがバズっていたが、AIでもDXでも、基本をしっかりやることが大事
これまでのソフトウェア開発は人間が主体だった
これからの主体がAIになるところと、人間が主体のままのところがある
測れなくなったもの
PRを見ても提出者が実装対象を理解しているのか分からなくなった
13:35 - 13:55 (20分) 事例: AI時代のガードレールとしてのAPIガバナンス
草薙 昭彦 氏 / Postman（株）テクノロジーエバンジェリスト ソフトウェア開発の主役が変わる
「AIがうまくやってくれるからAPI管理は不要」という誤解
実装スピードは上がるが、安全性とガバナンスをどう両立するか？
API乱立によるメンテナンスコストの指数関数的増大
APIを探すより作るほうが早い
責任の不明確性
裁量性の欠如
AI ガードレール
Permission
Approval
Audit
Kill Switch
静的な管理が不十分なまま動的ガードレールだけでAIを制御しようとするのは、非効率で危険
14:10 - 14:50 (40分) 公開Q&A: AI時代のエンジニアリングの原則② 〜t_wadaさんに直接聞く Q&Aセッション〜
Q. AI時代の勉強の方向性として、フルスタックのようにエンジニアリングの分野を広く浅く勉強していくのがいいのか、専門分野に絞って深い知見を得ていくべきなのか、はたまたAIの使い方を学ぶべきなのか、t_wadaさんはどう考えますか？新人の場合とシニアの場合で答えていただけるとなおありがたいです！
広く浅く流行っておいたほうがよい。
学び方としては、深堀はしやすくなっている。問いの連鎖ができる。
全体感を得る、専門分野はAIよりも得意、プログラミングは学ぶほうがよい
Q. エージェントはauto acceptが基本だというお話があり、個人的には同意です。一方で、セキュリティ観点で考えたときに、リテラシーが高くないメンバーも含めて全員にそれを推奨するのは、コンプライアンスを担当する者としては難しいと感じています。セキュリティ観点はどういった手法でクリアしていますか？
auto accept = deploy としてはいけない
リテラシーが高くないなら、高いいメンバーのレビューは必要
品質のなかの「セキュリティー」部分はできる人がそもそも少ないので、仕組みで解決するしかない AIが大量にくるなら、人間側も多人数で対応してく
リテラシーの低いメンバーがいるとして、リテラシーを高める教育をしていく必要がある
従来はコードレビュー等で教育を行っていたが、ほかの仕組みが必要になっていくだろう Q. コーディングエージェントを使って実装する場合、コーディングエージェントが実行したコードおよびテストコードをすべてチェックしていますか？質問の背景としては、開発スピードが上がった一方でコードレビューの(セルフでも他者でも)スピードは上がっておらず。ボトルネックが移動しただけでそこまで恩恵を受けれていないのがもやっとしてま
チェックしています(t-wada)
コードレビューはボトルネックですが、これまではコーディングがボトルネックではなかった
制約理論 TOC: ボトルネックは移動する、ボトルネック以外を速くしても意味がない Q. リソース効率をあげてもあまり意味がないよ、という話をもう少し深掘りして伺ってみたいです
人がコードを書いていた時代は、人（リソース）が空いていないこと = 効率が高い
GitHub Pull Request 時代は、一番コードを書けるシニアエンジニアにPRレビューが積み上がり、ボトルネックになった
つまり、制約理論にそって考えることが大事
Q. 新卒やジュニアのエンジニアの教育はどう変わっていくでしょうか？例えば、コーディングエージェントの伴走者として開発していくには、自身がペアプロを新卒にできるようなスキルが求められるようなものだと理解しています。今までのような小さなステップアップをしてもらう時間がなくなっているように感じて教育方針に悩んでいます
まさに難しくなったところ
「小さなステップアップをしてもらう時間がなくなっているように感じる」のが現在の社会の問題ではないか
開発効率の高い道具を全員が手に入れて、他社に抜かれないように作り続けることで、時間がなくなっている
shimizukawa.icon「モモ」みたいだ
誰もいらないものを高速に作れるようになっても意味がない
教育自体は中長期的に効いてくるものなので、教育をやりましょう
「質とスピード」はトレードオフではない
「質とスピード」のトレードオフは「教育」
「教育」は将来への投資で、将来の「質とスピード」を手に入れる方法
「教育」では基礎を学ぶのが大事（まわりまわって）
Q. 「理解容易性と変更容易性のトレードオフ」とは具体的にどう言語化してスキルに落とせば良いでしょうか？このままの表現でAIへ適切に伝わるイメージがなく事前にお聞きしたく
「理解容易性と変更容易性のトレードオフ」は通常はトレードオフではない
両方が高まったときに、最後どちらをとるか、という判断が必要になる
Q. 社内でAIの勉強会をすると、レベル感の違いに戸惑います。この場に来ている人は共通して何かしらの危機感を持っていると思いますが、他人事というか、ちょっと試して「あーAI使えないわ」で諦める人が一定数存在します。そういった人たちに対してどんなアプローチをすると良いと思われますか？
仕組化が大事
Q. 3rd-partyライブラリの今後の価値は、よく設計された仕様やテストになるのでしょうか？ 昨今はサプライチェーン攻撃の激しさが増しているため、大規模でないライブラリを内製する機運が高まっていると思います。この潮流の中で、3rd-partyライブラリが提供できる価値が気になっています。
手元で再実装してしまおうという時代になっている
3rd-partyライブラリの価値は、テスト、設計、ドキュメント、多人数が利用している、問題解決の期待値が高い
AIエージェントは攻撃者にとっても増幅器なので、ある程度内製に振るのは仕方がない
Q. アンラーニングすることが大事、コードを書く技術の重要性が下がる。とおっしゃっていましたが、コードの書き方を知っていないとAIとのペアプロという観点で上手くいかないのではないでしょうか？コードを書く技術としてどれくらいのベースを抑えておけばよい というような目安はありますか？
まだわからない
個人の考えとしては、コードの書き方をもっとたくさん知っていてほしい、コーディングスキルももっと伸ばしてほしい、それがAIコーディングと付き合っていく上で必要なスキルになっていく
しかし、自分でコードを書かない時代にそれをやってもらうのは難しい
対象を構造化して、分解して、順序付けて伝える、そういうスキルは今後も大事だと思う
15:00 - 15:15 マネジメント: LLM時代の検索アーキテクチャと技術的意思決定
（充電のため聞かなかった）
15:25 - 15:40 マネジメント: AI時代における具体と抽象の往復 - 日常にチャンスがある
（立ち見で聞けなかった）
15:40 - 16:20 (40分) キーノート: AI時代におけるエンジニアリング組織の変わるべき点、変わらない点
AIによるエンジニアリング組織が影響を受ける観点
開発プロセス
新メンバーの採用
ピープルマネジメント
エンジニアのキャリアパス
開発プロセス
現在地
開発速度は上がった
QA, E2E を速くするのが次の課題
人間に何を求めるか
官能試験のような人間の感覚が必要な部分（も本当にAIができないのか考える必要がある）
featureフラグで本番リリース後にAI向けに解除してテストさせる
変わらないこと
「やってほしいこと」を理解している必要がある
パフォーマンス課題の対応策を複数知っていて比較でいる知識は必要
変わること
ドキュメント執筆能力の重要性が大きくなる
他人が読んで理解可能な文章を書く能力
新メンバーの採用
ピープルマネジメント
目的は、チームが最も成果を出せるようにする
その人が成長するのに必要な負荷のもとにいるか？
エンジニアのキャリアパス
仕事の総量、継続的な学習
深い専門性を備えること
プロダクトマネジメントの方向に専門性を広げる
おやつ。
16:20 - 16:35 アーキテクト: AI時代における技術的負債への取り組み
重岡 正 氏 / （株）ROUTE06 取締役 CTO 兼 共同創業者 立ち見で聞きかじりました
16:45 - 17:00 アーキテクト:「責任あるAIエージェント」こそ自社で開発しよう！
17:05 - 17:35 (30分) ライトニングトーク（LT）: テーマ：「TechLeadやチーム開発に関わること」
17:45 - 18:25 (40分) キーノート: 変化の速いAI時代に、テックリードは何から見直すべきか
テーマ
AI活用がチームにうまく定着しないとき何から手を付けるか
個人のAI活用を、同チームのやり方として定着させるか
新しい概念や技術トレンドの本質を、どう見誤らずにとらえるか
AI活用がチームにうまく定着しないとき何から手を付けるか
内発的、自発的、ボトムアップ、でやっていては出遅れる
全員に体験させることは強力な福利厚生
見抜くべきは業務の情報構造、それをテックリードが形にしていく
当たり前になれば戻れなくなる
UnitTest、CI、CD がない時代 -> 準備は大変 -> 用意できればもう戻れない
個人のAI活用を、同チームのやり方として定着させるか
ある程度までのプロジェクトはチームを2名くらいまで落としたほうが身軽に動ける
30万行以下のサービスを10人以上でメンテしていく、という発想がずれている
属人化が良い悪いという軸が変わってきている
新しい概念や技術トレンドの本質を、どう見誤らずにとらえるか
新しい概念は、実際にはたいして新しくない
技術は螺旋、時代ごとに何度も同じ概念がやってくる
みんなが話して、用語が生まれて、本が出て、カンファレンスで紹介されて、それを「やろう」というのは「テックリードなんでしょうか？」
テックリードはもっと先にいきましょう
18:30 - 19:50 交流会（お酒や食事を楽しみながらのエンジニア交流会）